We will first see the PBO sub-program for both screens.
PBO modules are used for initializing variables, assigning the pf-statuses and titlebars for dynpros, and other screen processing to be done before the screen is displayed and re-displayed.
Include MZTRYO01
Module status_0100.
Clear : ztryemp, ztrydept, ztryrate, ztrytxn, v_date.
Set pf-status �STAT_100�.
Set titlebar �100�.
Endmodule.
Module status_0200 output.
If not v_emp_exist is initial.
Set pf-status �STAT_200� excluding c_save.
Set titlebar �200�.
Loop at screen.
If screen-group1 eq �GR1�.
Screen-active = c_0.
Modify screen.
Endif.
Endloop.
Else.
Set pf-status �STAT_0200�.
Loop at screen.
If screen-group2 eq �GR2�.
Screen-active = c_0.
Modify screen.
Endif.
Endloop.
Endif.
Move v_empno to ztryemp-empno.
Endmodule.
Double click on the pf-status and the titlebar to create the respective objects.
Note that the pushbuttons have been assigned groups to enable/disable them depending on certain conditions.
We will now see the PAI sub-program for both screens.
Write the PAI sub-programme
Double click on the pf-status and the titlebar to create the respective objects.
Note that the pushbuttons have been assigned groups to enable/disable them depending on certain conditions.
We will now see the PAI sub-program for both screens.
PAI modules are used for coding the various screen interactions done by the user, and for taking corresponding actions as per the requirements given by the user.
Include MZTRYI01
The user can press the BACK or CANCEL buttons before entering any data on the screen. In such a case, since the flow logic is executed sequentially in the order of modules placed in the PAI, the modules for validating various fields are also executed before the control goes out of the transaction. This displays unnecessary error messages even when the user has not entered any data.
To prevent this we use the concept of at exit-command. Here, some of the function codes are marked as exit-command function codes (E), by double clicking on the function code in the pf-status. Now we can associate a module which gets triggered when any of these function codes become active. This module hence is placed right at the beginning of the PAI. The control then goes out of the transaction before any of the field validation modules are executed, thus preventing the error messages.
This exit-command module looks like below.
Module exitscreen input.
Case v_okcode_100.
When �EXIT�.
Leave to screen 0.
when �BACK�.
Leave to screen 0.
when �CANCEL�.
Leave to screen 0.
Endcase.
Endmodule.
Module user_command_0100 input.
If ztryemp-empno is initial.
Leave to screen 100.
endif.
Case v_okcode_100.
When c_enter.
Perform check_emp_exist.
When others.
Endcase.
Endmodule.
Module user_command_0200 input.
Case v_okcode_200.
When c_modify.
Perform move_values.
Perform lock_table.
Perform change_dbase.
Perform unlock_table.
Message s999(z1) with text-001.
Leave to screen 100.
When c_save.
Perform move_values.
Perform lock_table.
Perform insert_dbase.
Perform unlock_table.
Message s999(z1) with text-002.
Leave to screen 100.
When c_delete.
Perform move_values.
Perform lock_table.
Perform delete_dbase.
Perform unlock_table.
Message s999(z1) with text-003.
Leave to screen 100.
When others.
Endcase.
Endmodule.
Double click on the form to create the object in the subprogram MZTRYF01. This subprogram will contain all the forms that we are coding for the transaction, to make the program modular.
Now we are in a position to code the respective forms to give a final shape to our transaction.
